FIG. 1 depicts the elements that make up a typical computer for use in presenting and maintaining an application. The computer 100 consists of a Base Computer 101 which comprises a processor 106, storage media such as a magnetic disk 107 and a high speed volatile main memory 105. An operating system and application programs 111 reside on the storage media 107 and are paged into main memory 105 as needed for computations performed by the processor 106. The Base computer may include optional peripheral devices including a video display 102, a printer or scanner 110, a keyboard 104, a pointing device (mouse) 103 and a connection 108 to a network 109. In a client environment, a user will interact with a (Graphical User Interface) GUI by use of a keyboard 104 and mouse 103 in conjunction with the display of information on the display 102 under control of an application program (application 1) 112. The client application program 112 will then interact with remote users by way of the network 109.
In FIG. 2 an example Internet system is shown. A user at client 1 201 uses applications on his system. This user (user 1 210) at client 1 201 can interact with clients 2–4 202–204 by way of a client server computer 206. Applications 112 may be provided by each client 201–205 and or the client server 206 or some remote server 208 by way of the network 207. The user at client 1 201 can interact with a remote user (user 5 211) at client 5 205 by way of the Internet 207.
Recently, peer to peer (P2P) interconnection has become an interesting alternative. FIG. 3 shows an example P2P network 300 wherein peer 1 301 can communicate with other peers directly. Each peer essentially includes client and server function. Thus, Peer 1 301 acts as a client in sending messages to Peer 2 302. Peer 2 performs some function as a result of receiving the message and may return a message to peer 1. Thus, peer 2 302 acts as a server for peer 1 301. P2P grids provide networked computers that cooperate to perform distributed computing.
Networked clients comprise applications for communication. E-mail applications provide for sending a message to a mail server that then makes the recipient aware of the waiting message. The recipient then can elect to open the message and view it at his client machine. E-mail messages can be sent, to a single recipient or can contain a list of several recipients (one to many). One to many e-mail transactions are popular with advertisers and the use of one to many e-mails has been dubbed “SPAM-ing”. Recently Instant Messaging (IM) has gained popularity in the form of sending text messages directly to another client. A first user composes an IM and selects a second user as the target. A message is then sent directly to the second user and appears on his display as either a message or the notification of a message. IMs are typical one to one messages.
Refer now to FIG. 4 which depicts a logical view of a pub/sub system of the prior art. A pub/sub service 404 receives messages originating from a content service 401–403 and delivers them to client subscribers 405 406. An example message published includes a topic string, a set of property name-value pairs, and a body. A subscriber identifies a topic string pattern and properties test, and receives matching messages according to a standard, for instance JAVA Message Service (JMS).
The pub/sub system is made up of a Content Provider application (Service) 401–403, the Subscriber (Client) 405–406, and the Pub-Sub Service 404. Applications may implement one or more of these roles. The content provider 401–403 generates content for distribution through the pub/sub system 400. Content providers 401–403 send structured content to one or more instances of the pub/sub service 404. The subscriber 405–406 sends subscription requests 407 to an instance of the pub/sub service 404 and, subject to acceptance of a particular subscription request, receives content 408 from the pub/sub service. The actual content received will be determined by the subscription and the message selection process.
The pub/sub service 404 acts as both a subscription manager 410 and a content distribution agent 411. Applications implementing the pub/sub service role 404 accept subscription requests 407 from subscribers 405 and, subject to any applicable authentication or access control policies, accept or reject subscription requests; and distribute content 408 to valid subscribers 405.
The actual content sent to each subscriber 405–406 by the pub-sub service 404 will be determined by the subscription process 410 and through the message selection process 411.
Applications implementing some aspect of the pub/sub system may act in different roles in different circumstances. For example, an application implementing the pub/sub service role 404 may itself act as a subscriber, subscribing to and receiving content from another instance of the pub-sub service. Similarly, an application acting in the subscriber role may act as a content producer if the end-user of the application wishes to publish a message to the service.
The pub/sub system provides for communication among applications implementing the application roles. There are two primary communications in the pub/sub system: messages are sent from content providers to pub/sub services; and pub/sub services send messages to subscribers 408, 412.
Content providers 401–403 may generate messages from any content source, and subscribers may dispose of messages in any manner they choose. For example, a content provider may simply be a gateway between a raw content source, such as e-mail or web pages, to the pub-sub service. Similarly, a subscriber 405, 406 may act as a gateway between the pub-sub service and an external service such as NNTP or e-mail. An application implementing a particular role defined in the Pub/Sub System may implement different roles at different times.
For example, an application implementing the pub/sub service role 404 may itself act as a subscriber, subscribing to content through another instance of the pub-sub service and receiving messages from that service.